Re: Fork a 119MB pagure project to updating monitoring?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Monday, 25 March 2019 21:45:06 CEST Jason L Tibbitts III wrote:
> >>>>> "JC" == Jeremy Cline <jeremy@xxxxxxxxxx> writes:
> 
> 
> JC> The effort would be a 1-2 line change in the-new-hotness, and
> JC> distributing the config to each package repository (some proven
> JC> packager could do this easily).
> 
> Well that seems easy enough.  We still need the repo for the bugzilla
> assignee override thing, but that's fine.  One thing at a time.
> 
> I can certainly drop commits into the repositories if that's what's
> needed.  We would need to define the name and contents of the file, and
> the default state for when the file is not present (to perhaps avoid
> touching every repository).
> 
> It might also be nice to know what on earth monitoring means for a
> module or a container, since the fedora-scm-requests has data for them
> but I don't understand what point it has.
> 
> We would also need to change the admin tool which is generating these
> files.  I think it would speed up its operation a good bit to not have
> to mess with this ever-growing repository, so that is a positive.
> (Especially since the tool does no local caching and so does a full
> clone each time it processes an SCM request).  And fedpkg request-repo
> would need to drop the --monitor option as it would have no effect.
> 
> So I guess it's more than just a couple of lines that need to change,
> but everything outside of the initial new-hotness change and the
> monitoring file commits could come later.
> 
>  - J<

Any chance this might happen?

 - A YAML (or TOML maybe) file at the root of the dist-git repo
 - name to be determined
 - the-new-hotness can look directly at the file and acts accordingly
 - some "fedpkg set-monitoring [no-monitoring,monitoring,monitoring-with-
scratch]" does the creation and commit of the file
 - --monitor is retired from fedpkg  request-repo
 - Make monitoring an opt-out only (that is we force all maintainers to run 
the commands fedpkg set-monitoring no-monitoring after the change if they 
really want to)

No idea what is the admin tool or what does it do.

On Tuesday, 26 March 2019 14:53:10 CEST Pierre-Yves Chibon wrote:
> > > The original idea, I believe, was to allow for the file to different per
> > > branch without breaking the one branch for all releases that many
> > > packager like. With modularity and stream branching, the ability to
> > > say: "I want PR filled for this version to this branch and for that
> > > version to that branch" would be neat, but this means having per-branch
> > > information that the-new-hotness will then access and act upon.
> > > Having this outside of the dist-git repo was meant to make it easier to
> > > tweak this file and have it diverge without having the different
> > > dist-git branches diverge.
> > 
> > If this is the reason than I don't think it's good idea to move the
> > monitoring file
> > to package repository, because the-new-hotness doesn't know which branch
> > should be used.
> > Right now I'm working on creating PR against dist-git in the-new-hotness,
> > but this
> > is basic feature and will create PR only against master branch, it's
> > than on packager to check, if this is correct.
> 
> The alternative would be to change the format to include the mapping version
> -> git branch.
> If we could do this in a backward compatible way it'd be great but that's
> always kinda hard.
> 
> 
> Pierre

Could we start simple and add a layer of complexity later on?
Could we keep all the infos in a single file in the master branch? 

I guess everyone is ENOTIME, but it would be great to see that issue progress.

Best regards,

Robert-André



_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux