Re: [DISCUSS][SOLR] Multiple Repos For Contributions
> By "hard to link", are you basically saying pasting URLs is hard Both JIRA and GH give nice visual indicators to the state of an issue when it is linked from another issue. When you manually create links, you lose that. That's all I was saying. I like JIRA because everything is in JIRA and I do not envy the person who has to move mountains to migrate it to whatever new system. I think Jan is right here - let each project choose for themselves. > But there are downsides to managing multiple repositories that make me > hesitant about the idea more generally. There's no easy way to > prevent changes in one repo from unintentionally breaking another. > There's at least some duplication in the maintenance of things all > repos need (build systems, etc.). It may add overhead on release > volunteers and the PMC if there are more releases. I tried to address some of these in my second mail to the thread. We'll need to invest in additional CI, and possibly in some ways to refactor and DRY the build config. I don't think adding overhead on releases is a problem - releases are kind of the reason we are all here anyway. If there's not enough motivation to make releases happen, then they won't happen, and that will be the end of it. > But maybe it'd make sense to use solr-operator as a test case for a few > releases before putting in the effort to move out our current contribs > or change our process of adopting new ones I agree with this, but for a huge caveat. Big things have been deprecated and removed, and users are going to be very confused on what to do when 9.0 comes around. I don't know to what extent it will impact adoption. But I'd rather have a plan and a narrative then going into it hoping for the best. At the same time, I really don't want to have to wait for the solr-operator experiment to settle before we can get a green light on 9.0 in general. But that's a different conversation. Mike On Wed, Nov 25, 2020 at 10:46 AM Jason Gerlowski wrote: > > then I'll start putting together individual proposals for a few repos to > exercise the process and get more contributions going > > solr-operator is a great example of PMC-maintained code that makes > sense to have in a separate repository. It's written primarily in a > different language, it's an integration with 3rd party software, etc. > > But there are downsides to managing multiple repositories that make me > hesitant about the idea more generally. There's no easy way to > prevent changes in one repo from unintentionally breaking another. > There's at least some duplication in the maintenance of things all > repos need (build systems, etc.). It may add overhead on release > volunteers and the PMC if there are more releases. > > I'm not sure how much those'll cause problems in practice. Hopefully > they'll be minimal, but it's possible they won't be. They might end > up outweighing the benefits. I'm not saying we should be afraid of > additional repositories where it makes sense for the domain. But > maybe it'd make sense to use solr-operator as a test case for a few > releases before putting in the effort to move out our current contribs > or change our process of adopting new ones. Since this is more about > long term management, and less about getting in a particular feature > or value for users, we've got a cool opportunity to let the > solr-operator experiment play out before we necessarily need to decide > how to handle similar scenarios. > > Just my two cents. > > Jason > > On Wed, Nov 25, 2020 at 8:23 AM Jan Høydahl wrote: > > > > Let each sub project decide for themselves. PYLUCENE has its own svn > repo and its own Jira space. > > Solr-operator should be allowed to continue with GH issues and PRs > i.m.o. No need to force them into JIRA as long as the ASF allows projects > to choose. > > > > Jan > > > > 24. nov. 2020 kl. 20:59 skrev David Smiley : > > > >> > Q: Should we create a separate JIRA for these contribs... or ditch > JIRA entirely for them, relying on GitHub alone? > >> > >> I'd start with same JIRA, with a separate component or label. I don't > think GH issues would be good because it becomes harder to link between > core and contrib issues in case of compat or tandme feature development. > > > > > > By "hard to link", are you basically saying pasting URLs is hard ;-). > ? There was a committer meeting in Montreal where some folks like Jan > Hoydal and Varun (if I'm not mistaken; I may be) advocated for considering > more GitHub centric issue tracking. I was not in favor of that... however > for contribs/modules that get their own separate repos, it affords an > opportunity for a break with the past in the interests of simplicity and > familiarity for what contributors are already familiar with. > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > > > > > On Tue, Nov 17, 2020 at 7:42 PM Mike Drob wrote: > >> > >> Thank you for the replies so far. > >> >
Re: Welcome Houston Putman to the PMC
Welcome Houston! Jan Høydahl > 1. des. 2020 kl. 22:19 skrev Mike Drob : > > I am pleased to announce that Houston Putman has accepted the PMC's > invitation to join. > > Congratulations and welcome, Houston! > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: SOLR: Why do we have a CHANGES.txt/md to maintain?
git-log is better than JIRA for this. A lot of projects generate release notes from it. here's a dirty stab at LUCENE 8.6.2 release notes looking similar to CHANGES.txt: git log --format=format:"* %s%n%b (%an)%n" --grep "^LUCENE" releases/lucene-solr/8.6.1..releases/lucene-solr/8.6.2 - * LUCENE-9224: (ant) RAT report complains about ... solr/webapp rat-report.xml (Simon Willnauer) * LUCENE-9478: Prevent DWPTDeleteQueue from referencing itself and leaking memory (#1779) In LUCENE-9304 we introduced some fixes that unfortunately hold on to the previous DWPTDeleteQueue which is essentially leaking IW memory and cause applications to fail. This fixes the memory leak and adds a test to ensure its not leaking memory. (Simon Willnauer) So it looks reasonable and can easily work, the problem is that commit messages need to be more consistent if you want to do fancy stuff like grouping and all that. On Wed, Dec 2, 2020 at 6:38 PM Rahul Goswami wrote: > > Couldn't help pitching in here and making a humble request. The CHANGES.txt > has been of immense help for us for determining the right upgrade version for > our production deployments. So CHANGES.txt or no CHANGES.txt, I hope we'll > retain a mechanism to clearly be able to track the changes in subsequent > versions. > > Thanks, > Rahul > > On Mon, Nov 30, 2020 at 9:04 AM David Smiley wrote: >> >> I get your point on different audiences... sometimes I peer-review us on >> dubiously written CHANGES.txt entries to be more user friendly. However, >> this attention could and should be given to JIRA issue summaries as well. >> We all benefit from that. Also, for Solr in particular, the need for >> examining CHANGES / JIRA is reduced because we have a >> solr-upgrade-notes.adoc which is editorialized and covers just the important >> stuff; no minor matters. We link to this from release announcements. >> >> ~ David Smiley >> Apache Lucene/Solr Search Developer >> http://www.linkedin.com/in/davidwsmiley >> >> >> On Mon, Nov 30, 2020 at 3:29 AM Adrien Grand wrote: >>> >>> I have a preference for maintaining a separate CHANGES file because it >>> allows us to keep JIRA focused for a committer/contributor audience while >>> the CHANGES file can describe changes that matter for users. Elasticsearch >>> uses a similar mechanism for release notes to what you are proposing, using >>> GitHub instead of JIRA. It works well, but in my opinion the Lucene/Solr >>> process produces better curated release notes. >>> >>> On Mon, Nov 30, 2020 at 12:25 AM David Smiley wrote: Well the commit history remains there as well and was converted from SVN and may eventually be converted to something else. My point is that it has been retained. On release boundaries, we could not only distribute Changes.html (a JIRA export) in the assembly (tar.gz) but we could also commit it to source control on each release branch, and thus will transfer along with source control into the future, which is way more convenient than digging up an old binary. ~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Sun, Nov 29, 2020 at 5:55 AM Dawid Weiss wrote: > > Changes in the repository stay there forever (think > cvs/svn/git/whatever comes next...). External tools change all the > time. This is the benefit I see. > > Dawid > > On Sun, Nov 29, 2020 at 6:32 AM David Smiley wrote: > > > > After recently proposing per-module CHANGES.md... I think I'd actually > > rather not have any CHANGES file at all to maintain. I'd rather go to > > JIRA with a bit better hygiene for metadata like > > components==contrib/module, and have some convenient links sprinkled > > about so that it's a convenient click away from each module. This > > proposal may not be as compelling for Lucene which has no > > solr-upgrade-notes.adoc file. > > > > Maintaining this CHANGES file (or files) is a pain. Formatting it > > just-so & conversion to HTML & other scripts manipulating it in > > dev-tools (e.g. add version), and branch syncing. It's commonly a > > source of merge conflicts more than any other file. It's an annoying > > step with GitHub PRs in particular. Why do we bother? Instead, on > > releases, provide a JIRA link to display all fixed issues grouped by > > issue type. We could export it to a file for direct inclusion in the > > distribution. JIRA even has a feature for this -- here's a direct link > > for 8.7: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310230=12348463 > > Notice the HTML version at the bottom. It could be dumped into the > > release binaries. > > Issue summaries tend to be much shorter than CHANGES.txt bullets but I > > think that's okay because it's not the only
Re: Welcome Houston Putman to the PMC
Welcome Houston! > On 1 Dec 2020, at 21:19, Mike Drob wrote: > > I am pleased to announce that Houston Putman has accepted the PMC's > invitation to join. > > Congratulations and welcome, Houston! > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
